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METHOD, SYSTEM, AND DEVICE FOR SPECIFYING SELECTIVE OVERRIDE OF 

DO-NOT-DISTURB FUNCTIONALITY 

FIELD OF THE INVENTION 

The invention relates to communication systems and 
5 more particularly to call management for systems which provide 
do-not-disturb (DnD) functions. 

BACKGROUND OF THE INVENTION 

In communications systems with voice call features, a 
user of a device or near a device is often alerted to an 

10 incoming call via an indication to the user in audible form 
such as a tone or ring, in kinesthetic form such as a 
vibration, or in visual form such as a flashing light. Some 
communications systems provide devices which alert the user in 
a relatively non-intrusive manner. However, there are 

15 situations when a user may decide not to receive an incoming 

call. In some communications systems, due to the way in which 
they operate, an incoming call and its alert can be intrusive 
and distracting or even dangerous. 

In wireless communication systems which provide 
2 0 dispatch services, push- to- talk™ (PTT™) services are often 
provided. Push- to- talk™ services typically provide 
walkie-talkie-like functionality or two-way half-duplex voice 
communication which enables a single user to communicate with 
another single user (as in a private session) or enables the 
25 single user to communicate with a group of other users (as in a 
group session) . When referred to herein, walkie-talkie-like 
functionality and half-duplex voice functionality are to be 
taken generally to mean any network delivered voice 
communication functionality which at any one time is capable of 
30 transmitting voice communication from a talking or transmitting 
party's device to a listening or receiving party's device, but 
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does not simultaneously transmit voice communication from the 
receiving party's device to the talking party's device, while 
the talking party's device is transmitting voice to the 
receiving party's device. Groups can operate in automatic 
5 answer mode or in manual answer mode. In push-to-talk™, for a 
group in automatic answer mode, voice reception is 
instantaneous, and requires no recipient action. For a group 
in manual answer mode, before voice reception, recipient action 
is required to accept or decline the incoming talk request. 
10 Situations may arise where automatic communication or a request 
for communication would be intrusive, and a user may wish to 
have no interruptions from calls for a period of time. 
Additionally, the user may wish not to have to take any action 
to deny talk requests during that period. 

In known systems, do-not -disturb (DnD) functionality 
is provided so that the user's device and hence the user are 
not disturbed by an incoming call. When this feature is active, 
no incoming call is offered to the user. DnD also blocks other 
forms of alerting, such as Message Waiting Notification 
alerting. Do-not -disturb makes the user inaccessible for call 
delivery. This DnD functionality is provided for users of half- 
duplex voice systems and full duplex voice systems, who do not 
want to be disturbed. This feature is also defined in IS-41- 
based systems. 

In known systems providing DnD such as the Push-to- 
Talk™ over Cellular (PoC) system (part of the OMA standard) , a 
user typically requests activation of DnD from the user device, 
which sends a request to a GLMS (group list management server) 
or similar call processing server to activate a DnD setting 
resident at the GLMS for the user device. Once the DnD setting 
has been changed in the GLMS to a state of do-not -disturb, the 
GLMS stops all subsequent incoming talk session requests 
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directed to the user's device. According to some standards 
this is accompanied by the GLMS sending a busy indication to 
the calling party. 

In addition to DnD management the GLMS performs 
access list management. Access lists are used to specify who 
is permitted or not permitted to establish a PTT™ session with 
a specific user device. Both a reject list, and an accept list 
can be stored for a user device, so that calls from specific 
user devices on these lists are respectively rejected or 
accepted automatically. 

A standard system architecture in which wireless 
dispatch call management is performed is defined by the OMA 
(open mobile alliance) standard. Depicted in Figure 1 is an 
OMA compliant system which includes push- to- talk™ over cellular 
(PoC) services. The overall architecture of the known OMA 
compliant system is generally indicated by reference numeral 
100, and includes a known GLMS (group list management server) 
110 which manages groups and lists (e.g. contact and access 
lists) that are needed for the PoC service. Also shown are the 
BTSs (base transceiver stations) 105,106,107 through which 
users can access the system. The illustrated example shows 
four user devices 101,102,103,104 having respective identifiers 
(ID) 001,002,003, and 004. 

The known GLMS 110 provides list management 
operations to create, modify, retrieve and delete groups and 
lists, and to provide storage therefor. Data store 12 0 
provides storage for the known GLMS which includes access lists 
and DnD flags stored by user device. The data for the DnD 
flags and access lists are shown in respect of known user 
devices 101, 102, and 103 in association with IDs 001,002,003. 
The access list is provided for each known user device (101, 
102, 103) and specifies which other known user devices are 
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permitted to reach the respective known user device (101, 102, 
or 103) over PoC . For example, for user device 101 having ID 
001, the access list contains 002,004,006, indicating that the 
device having these Ids are allowed to reach the user device 
5 101. The known GLMS 110 also stores for each known user device 
a DnD flag which may either be a "yes" or a "no" value which 
dictates whether or not the user device is in a state of do- 
not-disturb. Each user device's DnD flag and access list helps 
facilitate management of talk requests directed to that user 
10 device. 

According to the OMA standard, the user device is 
permitted to query and set the value of the DnD flag of that 
user device, but generally is not permitted to directly query 
or set the value of a DnD flag of another user device. 

15 Figure 1 depicts a known user device 104 with ID 004 

which is sending a group talk request 109 for a session with 
other known user devices 101, 102, and 103, all of which are 
part of the group as defined by OMA. The talk request 109 is 
received and forwarded by the Radio Access Network (RAN) 105 to 

20 the known system 100. Once the request is forwarded to the 

known GLMS 110, DnD Processing 13 0 and Access List Processing 
140 take place to determine if the talk request 109 is 
forwarded. Since each of the known user devices 101, 102, and 
103, has an associated DnD flag of "YES" in the data store 120 

25 of the known GLMS 110, none of the known user devices 101, 102, 
and 103, are forwarded the talk request 109 which would take 
place over RANs 106 and 107. 

Figure 2 shows the steps performed by a known GLMS in 
a known OMA compliant system to manage incoming calls for a 
30 user device using the stored DnD flag and access list for that 
user device. At step 115, the known GLMS receives an incoming 
talk request specifying the user device as the device being 



51085-6 

5 

called. In step 135 the known GLMS checks the DnD flag 
associated with the user device identified in the talk request. 
If the DnD flag is set to "NO" then processing of the call 
continues at step 145 wherein the access lists are processed to 
5 assess whether the talk request should be forwarded to the user 
device or not. If the DnD flag 130 is set to "YES" then the 
talk request is rejected in step 155, and the user's device is 
not disturbed. 

SUMMARY OF THE INVENTION 

10 The present invention provides methods, systems, and 

devices for selective override of do-not -disturb in a wireless 
communications network, in which a user is provided with an 
option to query and modify the ignoring of do -not -disturb (DnD) 
for certain reasons associated with an incoming call. In some 

15 embodiments, the DnD is ignored when the incoming call is an 
urgent call. In other embodiments DnD is ignored when an 
incoming call is an emergency call. In some embodiments a 
network call processing server manages and performs selective 
override of do -not -disturb in an OMA compatible system. In yet 

2 0 other embodiments, a mobile device is adapted to send to a 

dispatch network of the wireless communications network a 
request to query or modify an ignoreDnD attribute, including an 
ignoreDnD flag, along with associated ignoreDnD reasons. 

According to one broad aspect, the invention provides 
25 a method of talk request processing in a do-not-disturb (DnD) 
capable communication system, the method comprising: receiving 
a talk request for a requested communications session involving 
a user device capable of walkie-talkie-like functionality; and 
selectively overriding DnD functionality for the requested 

3 0 communications session as a function of an ignoreDnD attribute 

for the user device. 
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According to another broad aspect, the invention 
provides a talk request processing system in a do-not-disturb 
(DnD) capable communication system, the talk request processing 
system comprising: a receiver adapted to receive a talk request 
5 for a requested communications session involving a user device 
capable of walkie-talkie-like functionality; and a network call 
processing function adapted to selectively override DnD 
functionality for the requested communications session as a 
function of an ignoreDnD attribute for the user device. 

10 According to another broad aspect, the invention 

provides a user device capable of walkie-talkie-like 
functionality for a do-not-disturb (DnD) capable communication 
system, the user device comprising: a user interface adapted to 
accept an external input to modify an ignoreDnD attribute for 

15 the user device; an ignoreDnD attribute request generator 

responsive to said external input adapted to send a network 
call processing server a request to update an ignoreDnD 
attribute of the user device. 

According to yet another broad aspect, the invention 

2 0 provides a memory for storing data for access by a talk request 

processing system, comprising: a data structure stored in said 
memory, said data structure being an ignoreDnD attribute 
comprising at least one predetermined ignore reason value. 

Other aspects and features of the present invention 
25 will become apparent to those of ordinary skill in the art upon 
review of the following description of specific embodiments of 
the invention in conjunction with the accompanying figures. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Preferred embodiments of the invention will now be 

3 0 described with reference to the accompanying diagrams, in 

which : 
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FIG. 1 is a block diagram depicting elements of a 
known communications system participating in services having 
do -not -disturb functionality; 

FIG. 2 is a flow diagram illustrating the steps 
5 performed by a GLMS of a known communications system having do- 
not -disturb functionality in processing an incoming talk 
request to a user device; 

FIG. 3 is a block diagram depicting elements of a 
modified communications system participating in modified 
10 services having modified do-not -disturb functionality according 
to an embodiment of the invention; 

FIG. 4 is a flow diagram illustrating the steps 
performed by a modified communications system having modified 
do-not-disturb functionality for processing an incoming talk 
15 request to a user device according to another embodiment of the 
invention; 

FIG. 5A is a block diagram representation of a 
datagram for a modified DnD attribute according to a further 
embodiment of the invention; 

20 FIG. 5B is a block diagram representation of a 

datagram for a DnD flag and a datagram for a new ignoreDnD 
attribute according to yet another embodiment of the invention; 
and 

FIG. 6 is a block representation of a modified user 
25 device incorporating elements according to an alternate 
embodiment of the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 



In certain circumstances, it would be desirable that 
an incoming call be forwarded to a particular user device even 
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if that user device has its DnD flag set at a call processing 
server not to disturb the user. Such a situation may occur for 
example, in an emergency, or when the call is urgent or for any 
other reason the subscriber or user would deem that this should 
5 be the case. In such a situation, there is provided by various 
embodiments of the invention, methods, systems, and devices for 
ignoring the DnD flag under certain circumstances, and hence 
overriding the DnD flag, and for querying and modifying data 
stored for use in overriding the DnD flag. 

10 The examples which follow employ PTT™ capable PoC 

networks and wireless devices. More generally embodiments 
described herein are applicable in the context of any network 
and wireless device participating in network delivered walkie- 
talkie-like functionality, of which ptt™ is but one example. 

15 Referring to Figure 3, a modified OMA system 

implementing a modified OMA standard in which an example 
embodiment of the invention operates, will now be discussed. 

The modified OMA system of Figure 3 provides a 
modified push- to- talk™ over cellular (PoC) service according to 
20 the example embodiment, and incorporates a new ignoreDnD flag 
in conjunction with a new ignore reason list of ignore reason 
values to determine whether or not, for any particular talk 
request, the DnD flag of the called device is to be ignored, 
and hence DnD functionality overridden. 

25 With respect to structure, the specific modified 

system of Figure 3 generally indicated by reference numeral 
200, includes a modified GLMS (group list management server) 
210. The GLMS 210 is a specific example of a call processing 
server. The GLMS 210 includes a data store 220, an access list 

30 processing unit 240, an ignoreDnD processing unit 250, and a 
DnD processing unit 230. The data store 220, access list 
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processing unit 24 0, ignoreDnD processing unit 2 50, and DnD 
processing unit 230 are coupled to each other for data 
exchange . 

Other embodiments employ different elements of the 
5 system to perform similar functionality to that performed by 
the units 250, 240, 230, of the GLMS 210 of Figure 3. In some 
embodiments, each one of the GLMS 210 and the units 250, 240, 
23 0, may be implemented in hardware, software, firmware, or any 
combination of hardware, software and firmware. 

10 Also shown are three RANs (radio access networks) 

2 05, 206, and 2 07 of the system coupled through the system 2 00 
to the GLMS 210, and four user devices 201, 2 02, 2 03, and 2 04 
having identifiers 011,012,013,014 respectively which may be 
actively coupled to the system via RANs 205, 2 06, and 207. 

The example of Figure 3 shows DND processing unit 
230, ignoreDnD processing unit 250 and access list processing 
unit 240 as separate elements. More generally, these may be 
implemented separately, or in combination, and may be 
implemented in hardware, software, firmware, or any combination 
of hardware, software and firmware. In a preferred embodiment, 
this functionality is included as software which is added to 
call processing functionality which would be conventionally 
provided in the GLMS 210. This new functionality may be 
provided on the GLMS 210 as shown in Figure 3, and/or may be 
implemented on a separate device or devices, in a distributed 
or consolidated manner. Alternatively this functionality may 
be provided independent of the GLMS, such as would necessarily 
be the case in systems not having a GLMS. 

The example of Figure 3 is particular to GLMS in an 
30 OMA context. However, OMA implementations are not limited to 

the example of Figure 3. Furthermore, while OMA is employed as 
the basis for the example of Figure 3, more generally, 
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embodiments of the invention are applicable in any context in 
which DnD functionality (or DnD-like functionality) is being 
employed in networks providing a walkie-talkie-like function. 

Also, the example of Figure 3 shows a network 
5 consisting of three RANs 205,206,207, and a GLMS 210. More 

generally, any appropriate network capable of providing walkie- 
talkie -like connectivity can be employed. This may employ 
greater or fewer than three RANs, or may employ different 
equipment altogether. Also, the example of Figure 3 shows four 
10 user devices 201,202,203,204. The actual number of users in a 
given system will typically be a transient characteristic. A 
greater or fewer number of users may be present at any given 
instant . 

The data store 220 contains DnD flags and access 

15 lists in respect of user devices having identifiers 011, 012, 
and 013. By way of example, the data for the user device 201 
having identifier 011 is indicated generally by 271. The 
device identifiers may be of any suitable form depending upon 
the system and network in which they are implemented. The 

20 access list, such as access list 274 for user device 201, is 
provided for each user device (201, 202, 203) and specifies 
which other users are permitted to reach the respective user 
device (201, 202, or 203) over PoC . The modified GLMS 210 also 
stores for each user device a DnD flag, such as DnD flag 273 

25 for user device 201, which may either be a "YES" or a "NO" . 
Other embodiments utilize a DnD flag 273 which is a logical 
boolean flag having two possible values; true and false. In 
further embodiments, the DnD flag 273 may be any form of data 
or data type which may have any number of possible values 

3 0 capable of representing the presence or absence of a do-not - 
disturb state, or equivalently the presence or absence of a 
w f ree-to-disturb" state. Additionally, the modified GLMS 210 
stores an ignoreDnD flag for each user device, such as 



51085-6 

11 

ignoreDND flag 275 for user device Oil (which may have a value 
of "YES" or "NO" ) and an ignore reason list 276 for each user 
device. The ignoreDnD flag 275 and the ignore reason list 276 
together form an ignoreDnD attribute 277. In some embodiments 
5 the ignoreDnD flag 2 75 is a logical boolean flag having two 
possible values; true and false. In other embodiments, the 
ignoreDnD flag 2 75 may be any form of data or data type which 
may have any number of possible values, capable of representing 
whether or not the DnD flag (or other information) is to be 

10 ignored (overriden) . The ignore reason list is for storing one 
or more reasons which a user may select to narrow down the 
circumstances in which the DnD flag is to be ignored. Examples 
of reasons are "urgent" and "emergency" , but any suitable set 
of reasons may be allowed in a given system. Furthermore, in 

15 some embodiments, no ignore reasons list is employed at all. 

Rather ignoreDnD processing proceeds solely on the basis of the 
ignoreDnD flag. Each user device's DnD flag, ignoreDnD flag, 
ignore reason list, and access list helps facilitate management 
of talk requests directed to that user device. 

20 In operation, the modified GLMS 210 manages groups 

and lists (e.g. contact and access lists) that are used for the 
modified PoC service. Specifically, the GLMS 210 provides list 
management operations to create, modify, retrieve and delete 
groups and lists, and to provide storage therefor. Data store 

25 220 provides storage for the modified GLMS 210 including access 
lists 274, DnD flags 271, ignoreDnD flags 275, and ignore 
reason lists 276 by user device. The DnD processing unit 230 
performs modified DND processing 23 0, the ignoreDnD processing 
unit 250 performs new ignoreDnD processing, and access list 

30 processing unit 240 performs access list processing. 



As with the DnD flags of the standard OMA system, in 
the modified system depicted in Figure 3, a user is allowed to 
select the value of the ignoreDnD flag and the ignore reason 
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list stored in the GLMS 110 for the user's device. This can be 
done by enhancing the current method that is used to update the 
access list in GLMS. 

In some embodiments the user can also query the 
5 current values of the ignoreDnD flag and ignore reasons list. 

In this embodiment the user is not permitted to query 
or set the value of the ignoreDnD flag or any value of the 
ignore reason list of any other user's device. In other 
embodiments, a class of special users such as administrators 
10 may be given permissions to query and/or modify the value of 

the ignoreDnD flag and the values in the ignore reason list of 
other user's devices. 

RANs 205, 206, and 207 are for transmitting and 
receiving signals over channels between the network 2 00, and 
user devices. An example of a specific configuration is shown 
in Figure 3, in which at one moment in time user device 204 is 
in communication with RAN 205. RAN 2 06 is in communication 
with user devices 202 and 203. User device 201 is neither 
receiving nor transmitting to any particular RAN. Radio access 
network 207 is neither receiving nor transmitting any signals 
to any particular user device. It should be understood that 
the particular configuration of user devices and base 
transceiver stations represents a "snapshot" of a possible 
configuration of user devices in communication with the system 
200, and in general at different times will have different 
numbers of user devices and different types of connections to 
different user devices depending upon what is happening within 
the network at that time. 

In the specific call and talk request processing 
3 0 example shown in Figure 3, the user device 2 04 with ID 014 
sends a group talk request as per the underlying PTT™ 
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initiation protocol for a session with user devices 201, 202, 
and 203, all of which are part of the group. The talk request 
209 is marked as "urgent" and is received and forwarded by RAN 
205 to the modified system 200. The existing ptt™ initiation 
5 protocol can be enhanced to include a priority of each call 
request. Once the request is forwarded to the modified GLMS 
210, ignoreDnD processing takes place in ignoreDnD processing 
unit 250, DnD processing takes place in DnD processing unit 
230, and access list processing 240 take place to determine if 
10 the talk request 209 is to be forwarded. 

In the illustrated example, each of the user devices 
201, 202, and 203, have an associated DnD flag 273 of "YES" in 
the data store 220 of the GLMS 110. If all of the user devices 
had ignoreDnD flag 275 values of "NO", then none of the user 
15 devices 201, 2 02, and 2 03, would be forwarded the talk request 
209 . 

In the example given in Figure 3, the ignoreDnD flag 
275 of each of devices 201, 202, and 203 is set to "YES". User 
device 2 01 (ID 011) has one ignore reason value, namely "EMERG" 
20 for emergency, associated with it. User device 202 (ID 012) 
has two ignore reason values, namely "URG" for urgent, and 
"EMERG", associated with it. User device 203 (ID 013) has one 
ignore reason value, namely "URG", associated with it. 

The user device requesting to talk has sent an 
25 "urgent" talk request, and hence only those user devices for 
which there is an ignore reason value of "urgent" will be 
forwarded the talk request. Any users whose DnD flag is not 
set will also be forwarded the talk request. As such only user 
devices 202 and 2 03 (having IDs 012 and 013) are forwarded 
30 respective talk requests 219 and 229 via RAN 206. 
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Figure 4 shows the steps performed by a modified call 
service management server in a modified communications system 
according to an example embodiment to manage incoming calls for 
a user device. A call processing function, for example a call 
5 processing server (CPS) , manages the incoming calls with use of 
a new ignoreDnD flag, a new ignore reason list, and a stored 
DnD flag, and an access list for the user device. 

At step 215, the network receives an incoming talk 
request specifying the user device as the target device which 
10 is being sent the talk request. In step 255 the modified GLMS 
checks the ignoreDnD flag associated with the target device. 

If the ignoreDnD flag is set to "NO" then DnD 
functionality is not overridden and processing of the talk 
request continues at step 235 wherein the DnD flag is tested, 
15 and if the DnD flag is "YES", the talk request is rejected in 
step 265 and if the tested DnD flag is "NO", processing of the 
talk request continues to the step of processing access lists 
245. 

If the ignoreDnD flag is set to "YES" then processing 
20 of the talk request continues at step 257 wherein the ignore 

reason list is compared to a criterion or condition of the talk 
request. If any of the ignore reason values matches a 
criterion or condition of the talk request, processing of the 
talk request proceeds to the step of processing access lists 
25 245, and the DnD functionality (step 235) is ignored and 

overridden. If none of the ignore reason values match the 
criteria of the talk request, the DnD functionality is not 
overridden, the DnD flag is tested at step 235, and if the DnD 
flag is "YES", the talk request is rejected in step 265 and if 
30 the DnD flag is "NO", processing of the talk request continues 
to the next step of processing access lists 245. 
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In some embodiments, the step 23 5 along with 2 65 and 
245 collectively are responsible for DnD functionality. In 
some embodiments, the steps 255 and 257 collectively are 
responsible for ignoreDnD attribute processing. 

5 It should be noted that although the particular 

embodiments depicted have utilized an ignoreDnD flag, in some 
embodiments, no ignoreDnD flag is used, and instead, the talk 
request processing proceeds directly from receiving the talk 
request at step 215 to comparing the ignore reason list of step 

10 257. In such an embodiment, DnD functionality is ignored only 
if any one of the ignore reason values matches a current state 
of the talk request. If a user wishes always to ignore DnD 
functionality, the ignore reason list is set to contain every 
possible criteria of a talk request, and if the user wanted not 

15 to be disturbed by any call, the list would contain no possible 
status for any talk request. 

Referring to Figure 5A, a datagram depicting an 

example of a modified DnD Attribute 3 0 of a modified OMA system 

according to a preferred embodiment of the invention will now 
20 be described. 

In this particular preferred embodiment the ignoreDnD 
flag 306 and ignore reason list 308 are incorporated into an 
ignoreDnD attribute 305 of a modified DnD attribute 300. The 
standard DnD flag 3 02 forms part of the DnD attribute 3 00 and 

25 its value is a 1-bit boolean 302. The ignoreDnD attribute 305 
includes an ignoreDnD flag 306 which has as its value a 1-bit 
boolean, and an ignore reason list 308, which lists up to four 
possible reasons why the DnD should be ignored, each reason 
having as its value a 2 -bit value. Each of these variables may 

3 0 be of longer or shorter bit -length depending upon the specific 
implementation. In some embodiments, there may be more than 
four ignore reasons and hence the bit -length would be longer 
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than 2 -bits. The example of Figure 5A shows headings "DnD 
attribute" etc. In an actual data store, these headings do not 
need to be stored as the location of contents is known. 

In other embodiments, the DnD flag is always ignored 
5 if the incoming call is an emergency call, and hence the 

ignoreDnD flag would not be required, as long as the ignore 
reasons were always processed. Conversely, in such an 
embodiment, an ignoreDnD flag could be set to "YES" and no 
reason provided as long as the ignoreDnD is only set to "YES" 
10 for emergency calls, and if the method step 257 of determining 
if any ignore reasons match a criterion of the request is 
always skipped. 

In some embodiments, any one 2 -bit encoded reason may 
represent a state that the talk request must meet . In the 

15 particular preferred embodiment illustrated in Figure 5A, each 
of the 2 -bit encoded reasons may be any one selected from the 
group of, 00 (Emergency) , 01 (Urgent) , 10 reservel, 11 
reserve2 . In this embodiment, the GLMS can be updated by a 
user at any time as part of a user's change of profile. These 

2 0 reasons are not encoded in the ptt™ request itself, only the 
PTT™ call type (for example an emergency call or an urgent 
call) is encoded in the PTT™ request. The existing protocol can 
be enhanced to include the call type in the call request and 
ignore DnD reason in the user change request . 

2 5 Referring to Figure 5B, datagrams depicting a 

standard DnD flag 401 which has a single 1-bit boolean value 
402, and a new ignoreDnD attribute 405 according to a second 
preferred embodiment of the invention will now be described. 



In this second preferred embodiment an ignoreDnD flag 
3 0 406 and an ignore reason list 408 are incorporated into a new 

ignoreDnD attribute 405. The standard DnD flag 401 is separate 
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from the ignoreDnD attribute 405 and its value is a 1-bit 
boolean 402. The ignoreDnD flag has its value a 1-bit boolean 
408. Each entry in the ignore reason list 408, which lists 
possible reasons why the DnD should be ignored, is a 2 -bit 
5 value 4 08. 

In some embodiments, any one 2 -bit encoded reason may 
represent a state or criterion that the talk request must meet. 
For example, the 2 -bit reason could represent a 2 -bit state 
flag accompanying the talk request or a 2 -bit state flag 

10 rendered in response to receipt of the talk request to reflect 
the state of the talk request. In the particular preferred 
embodiment illustrated in Figure 5A, each of the 2 -bit encoded 
reasons may be any one selected from the group of, 0 0 
(Emergency) , 01 (Urgent) , 10 reserve, and 11 reserve, and any 

15 talk request may, but not necessarily, be characterized as 
being an emergency request (00) , an urgent request (01) , or 
neither . 

Referring now to Figure 6, a modified user device in 
the form of a wireless mobile device generally indicated by 

2 0 reference number 500 according to a specific embodiment of the 

invention, will now be discussed. 

In this embodiment, to provide a user of the user 
device the ability to query and set the new ignoreDnD and 
ignore reason values, new functionality is incorporated in the 
25 user device 500 itself. In this embodiment a user would make a 
selection using any suitable form of user interface (UI) which 
could be, for example, but not limited to, keys 515, touch 
screen capability of a user interface (UI) display screen 510, 
or a voice command responsive interface, to select, query or 

3 0 modify a value for one of the ignoreDnD flag, or ignore reason 

values. In response to the user selecting this function from 
the interface modified by new functionality for request data 
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input editor 530, the user interface displays choices of which 
of the new variables to change and provide functionality for 
editing them in accordance with the possible range of values 
each may have. Once the user has finished editing the query 
5 request or modify setting request, the new request generator 
52 0 is adapted to send a request to query and/or modify 
settings of the new variables in the network, for example in 
the GLMS . In a preferred embodiment, the request generator, 
and the request data input/editor are implemented as 
10 additions/modifications to software running on the device 500. 
Alternatively separate hardware and/or software and/or firmware 
may be used. The existing protocol can be enhanced for users 
to change their DnD setting profiles. 

Although the specific embodiments presented herein 
15 are in respect of PoC versions of ptt™, any voice 

communications system which uses do-not-disturb functionality 
could be adapted in accordance with the invention to provide 
functionality to ignore the do-not-disturb state in certain 
circumstances . 

2 0 It should be understood that although the specific 

embodiments presented herein are in accordance with an adapted 
OMA system and standard, that other communications systems and 
standards for example but not limited to GSM, TDMA, and CDMA, 
could be adapted according to the invention to provide 
25 functionality to ignore or bypass do-not-disturb functionality 
in certain circumstances or for certain talk requests. 

In other embodiments, the method and system are 
adapted to provide peripheral support for a wired device which 
is capable of participating in wireless sessions with various 

3 0 talkgroups, and which has an associated ignoreDnD attribute and 

services provided therefor. Such a wired device participates 
via a network interworking function, so that although the wired 
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device is not within the wireless network, it appears as though 
it is, and participates in a group call like a wireless device. 
Hence, according to these embodiments, the wired user device is 
provided with services to enable query and modifications to the 
5 ignoreDnD attribute so that DnD may be overridden. For these 
embodiments, talk request processing along with do-not -disturb 
functionality occurs in a manner analogous to the manner 
described hereinabove. 

Numerous modifications and variations of the present 
10 invention are possible in light of the above teachings. It is 
therefore to be understood that within the scope of the 
appended claims, the invention may be practiced otherwise than 
as specifically described herein. 



